En lo personal no sabia que la "ley de secreto bancario suizo" fuera el resultado tanto del lobbyismo de los mas ricos por esconder sus capitales de las garras de las instituciones tributarias de sus paises, como tambien de una cierta leyenda relacionada a la proteccion de las riquezas judias contra la avaricia del Estado Aleman bajo Hitler.

De acuerdo a https://mpr21.info/el-verdadero-origen-del-secreto-bancario-suizo/ la gestacion de esta regulacion se inicio basicamente una vez las oficinas tributarias alemanas comenzaron a perseguir a quienes no querian pagar impuestos a inicios del 33, pero que poco despues se reforzo gracias a la naciente dictadura #nazi

Y todo de cara a las supuestamente feroces discusiones que se venian dando en el congreso de Los Esclavos Unidos, principal interesado en que los capitales no salieran de sus fronteras.

No tengo los datos a la mano, pero si leemos https://www.bbc.com/mundo/noticias/2016/04/160408_historia_paraisos_fiscales_offshore_finde veremos que son justamente los que se autodenominan paladines de la #justicia, quienes fueron los primeros en levantar los primeros paraisos fiscales de la era moderna.

Los Esclavos Unidos se caraterizan por ofrecer decenas de lugares donde las leyes son muy poco transparentes y permiten la creacion de cuentas en la oscuridad o empresas de papel que o no pagan impuestos o pagan realmente una miseria.

La Gran Bretaña tambien se sumo a esta tendencia, creando un marco juridico a favor de la evasion de impuesto y la instauracion de los llamados "buzones de papel", que despues saldrian a la palestra mundialmente en los "papeles de Panama".

Suiza solo habria coronado lo anterior con su legislacion a favor del "secreto bancario" para asi darle el vamos a cuanto Estado, pais o territorio a la hora de ofrecer mas y mejores condiciones a quienes buscaban esconder cuantiosos capitales fuera del radar de las oficinas tributarias locales.

Una cuestion en este tema es trascendental y es basicamente que ninguna ley anti-paraisos fiscales sera suficiente mientras la falta de #transparencia sea la norma que domine esta cuestion.

Lo que #wikileaks en palabras de #FreeAssange dijo, son justamente lo que probablemente lo llevo a la persecucion, encierro y el sufrimiento de torturas de por vida:

"Transparencia para los poderosos (de arriba), #privacidad para los de abajo (debiles)"

Join the FSF and friends on Friday, December 22, from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

https://www.fsf.org/events/fsd-20231222-irc

IDAD may be over, but the fight isn't. Read a summary of this year's activities, and learn how you can continue to take action to help end DRM.

https://www.fsf.org/blogs/community/our-work-isnt-over-keep-fighting-for-the-freedom-to-learn

https://www.tntech.edu/news/releases/22-23/tech-tapped-to-lead-multi-state-consortium-on-electric-grid-modernization-backed-with-largest-grant-in-tech-history.php

https://www.tennessean.com/story/sponsor-story/tennessee-tech/2023/11/22/tennessee-techs-research-will-impact-hundreds-of-businesses/71658586007/

"This is expected to include seven rural electric utilities, one energy tech startup, 60 electrical engineering firms and 400 freelance software developers. The work will impact 191 counties across Tennessee, Ohio, Pennsylvania and West Virginia."

"Students will experiment in a real-time simulated environment so electric utilities can provide cost-effective testing and solutions prior to the implementation."

https://savannah.gnu.org/news/?id=10567

Today my girlfriend Vivi Langdon (EncryptedWhispers) and I released the music video In Unexpected Places, availableon YouTube andon PeerTube both. It's based off of Vivi's song by the same name, availableon BandCampand on Vivi's Funkwhale instance! It features some kind of retro video-game'y aesthetics but its story departs from what you might expect from that while leveraging that, more on this below.

Everything was made with Blender, including some hand-drawn effects using Blender's excellentGrease Pencil! The video is also an open movie project; you candownload the full .blend file, which is CC BY-SA 4.0, and play around with everything yourself. The eye rig is especially fun to control and the ships are too!

All in all this was project took about 6 months of "free time" (read: weekends, especially at Hack & Craft) to animate. I played the music over and over again until I had a good story to accompany it and then on a car trip I drewthe storyboardon a pile of index cards from the passenger seat while Morgan was driving, and when I got home I pulled up Blender quickly and timed everything with the storyboard. That storyboard was meant just for me, so it doesn't really lookparticularly good, but it convinced me that this was going to work, and thefinal animationmatches that hastily drawn storyboard very closely!

The title was Vivi's choosing and was selected after I storyboarded the video. It references the phrase "love is found in unexpected places" and references both the eye falling in love with the cube but also that this music video was made shortly after Vivi and I fell in love (which also happened in ways that felt surprising to be swept up into, in a good way), and a lot of the depth of our relationship grew during the half-year of making the video.

Some commentary about the narrative

You should watch the video yourself firstbefore reading this section to develop your own interpretation! But if you are interested in my interpretation as author of the animation and its script, here we go.

The video is a commentary about violence and the ways we are conditioned. Without having watched the entire narrative, having just seen clips of the "action sequences", this might look like a video game, and a viewer used to playing video games of the genre seen (of which I am exactly the type of person who both plays and makes games of this genre, including with these tropes) would be most likely to identify with and assume that the two ships which circle and attack the eye are the "heroes" of the piece. Of course, we can see from the comments here that most people are identifying with the eye, which was the intention. Which then puts the viewer at a seeming contradiction: identifying with the character they would normally be attacking.

Of course, villain-subversion tropes are hardly new, particularly within the last couple of decades. But here I wanted to do so without any written story or narrative. In particular, the question is to highlight social conditioning. If I play a game and I see an eyeball in space, I'm gonna want to shoot it! But what will you think the next time you see a floating eyeball in a video game and assume you're supposed to hurt it? The goal is to get you thinking about the way we are conditioned from small signals towards aggression and confrontation and to instead take a moment to try to approach from a point of empathy. That the eye falls in love with the cube at the beginning, and then when disabled or killed at the end is unable to "see" the cube it fell in love with, is meant to be a bridge to help the viewer along that journey. (The goal here is to less criticize video game violence and more the kinds of conditioning we experience in general, though you could use it to criticize that too if you like.)

Likewise, aside from the two ships that destroy the eye, there were two prior ships that also seemed to be aggressive against the eye. These are what I called the "scanner ships": they gather information on the eye, and they confuse and irritate it but not in terms of long term damage the way the "player ships" do, not directly. Instead what they are doing is gathering information to send the players, hence the "speech balloons with antennae on them". This is your briefing at the start of the level, telling you in Star Fox or whatever what your objective is. Their goal is to provide something "fun" for the players to attack and destroy so that they may level up. They represent the kind of media that we consume which pre-conditions us against empathy and towards aggression.

Of course, this is just one interpretation, and it is not the only valid one. I have heard some interesting interpretations about this video being about the way we are pushed into engagement driven consumption platforms and how it hurts us, and another about this being about the way we wake up within the world and have to struggle with what is thrown at us, and another which was just "whoa cool, videogames!", and all of those are valid.

Regardless, I hope you enjoy. As a side note: no sound effects were added to the music video, all of those were in the song. I shaped the story around the song... you could say that the story "grew" from the song. So amongst all the rest of the story above, the real goal was to deliver an experience. I hope you enjoyed it!

https://dustycloud.org/blog/in-unexpected-places/

Christine Lemmer-Webber

2023-12-19 13:59:20

In Unexpected Places

The story of an eye that falls in love with a cube.

Music by EncryptedWhispers. Video created by Christine Lemmer-Webber in Blender with Grease Pencil!
Everything--the song and music video--is released under Creative Commons Attribution-ShareAlike 4.0 International.

👁️ Support the artist by purchasing the song on Bandcamp: https://encryptedwhispers.bandcamp.com/track/in-unexpected-places (use discount code "unexpected" and you can get it for 25¢ USD!)
👁️ You can also download the song in FLAC for free from the artist's FunkWhale: https://audio.solarpunk.moe/library/tracks/517/
👁️ Download the source file for the animation: https://dustycloud.org/gfx/goodies/in-unexpected-places-packed.blend

This music video is also on YouTube, if you're into that kind of thing:

in unexpected places, by EncryptedWhispers

track by EncryptedWhispers

^{EncryptedWhispers}

Late last year I switched blog entries and comments to be written in a dialect of markdown, but there was a bug that I never noticed: if a text consisted only of a single paragraph or block, it would trigger an error that got reported back to the user in a very strange way, and which would prevent the comment from being posted.

I had never seen the error myself because blog posts are generally more than a paragraph, but it must have been quite irritating when commenting. Sorry about that; it should be fixed now. Should you experience more strange errors, please do send me an email with the comment to wingo@igalia.com. Cheers.

https://wingolog.org/archives/2023/12/14/service-update

Watch and share our video to help educate friends and family about software freedom and why it is so very important.

https://www.fsf.org/blogs/community/share-this-holiday-fairy-tale-with-your-loved-ones

I know, dear reader: of course you have already seen all my talks this year. Your attentions are really too kind and I thank you. But those other people, maybe you share one talk with them, and then they ask you for more, and you have to go stalking back through the archives to slake their nerd-thirst. This happens all the time, right?

I was thinking of you this morning and I said to myself, why don’t I put together a post linking to all of my talks in 2023, so that you can just send them a link; here we are. You are very welcome, it is really my pleasure.

2023 talks

Scheme + Wasm + GC = MVP: Hoot Scheme-to-Wasm compiler update. Wasm standards group, Munich, 11 Oct 2023.slides

Scheme to Wasm: Use and misuse of the GC proposal.Wasm GC subgroup, 18 Apr 2023.slides

A world to win: WebAssembly for the rest of us.BOB, Berlin, 17 Mar 2023.blogslidesyoutube

Cross-platform mobile UI: “Compilers, compilers everywhere”.EOSS, Prague, 27 June 2023.slidesyoutubeblogblogblogblogblogblog

CPS Soup: A functional intermediate language.Spritely, remote, 10 May 2023.blogslides

Whippet: A new GC for Guile.FOSDEM, Brussels, 4 Feb 2023.blogeventslides

but wait, there’s more

Still here? The full talks archive will surely fill your cup.

https://wingolog.org/archives/2023/12/12/sir-talks-a-lot

We're doing a matching campaign that triples every donation, up to $15,500 made between Tuesday, December 12 and Thursday, December 14.

https://www.fsf.org/blogs/community/triple-your-donation-fsf-matching-challenge-until-december-14

Join the FSF and friends on Friday, December 15, from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

https://www.fsf.org/events/fsd-20231215-irc

Good evening! This evening, a note on high-dynamic-range (HDR) histograms.

problem

How should one record garbage collector pause times?

A few options present themselves: you could just record the total pause time. Or, also record the total number of collections, which allows you to compute the average. Maximum is easy enough, too. But then you might also want the median or the p90 or the p99, and these percentile values are more gnarly: you either need to record all the pause times, which can itself become a memory leak, or you need to approximate via a histogram.

Let’s assume that you decide on the histogram approach. How should you compute the bins? It would be nice to have microsecond accuracy on the small end, but if you bin by microsecond you could end up having millions of bins, which is not what you want. On the other end you might have multi-second GC pauses, and you definitely want to be able to record those values.

Consider, though, that it’s not so important to have microsecond precision for a 2-second pause. This points in a direction of wanting bins that are relatively close to each other, but whose absoluteseparation can vary depending on whether we are measuring microseconds or milliseconds. You want approximately uniform precision over a high dynamic range.

logarithmic binning

The basic observation is that you should be able to make a histogram that gives you, say, 3 significant figures on measured values. Such a histogram would count anything between 1230 and 1240 in the same bin, and similarly for 12300 and 12400. The gap between bins increases as the number of digits grows.

Of course computers prefer base-2 numbers over base-10, so let’s do that. Say we are measuring nanoseconds, and the maximum number of seconds we expect is 100 or so. There are about 230nanoseconds in a second, and 100 is a little less than 27, so that gives us a range of 37 bits. Let’s say we want a precision of 4 significant base-2 digits, or 4 bits; then we will have one set of 24 bins for 10-bit values, another for 11-bit values, and so-on, for a total of 37 × 24 bins, or 592 bins. If we use a 32-bit integer count per bin, such a histogram would be 2.5kB or so, which I think is acceptable.

Say you go to compute the bin for a value. Firstly, note that there are some values that do not have 4 significant bits: if you record a measurement of 1 nanosecond, presumably that is just 1 significant figure. These are like thedenormals in floating-point numbers. Let’s just say that recording a value val in [0, 24-1] goes to bin val.

If val is 24 or more, then we compute the major andminor components. The major component is the number of bits needed to represent val, minus the 4 precision bits. We can define it like this in C, assuming that val is a 64-bit value:
#define max_value_bits 37
#define precision 4
uint64_t major = 64ULL - __builtin_clzl(val) - precision;

The 64 - __builtin_clzl(val) gives us the ceiling of the base-2 logarithm of the value. And actually, to take into account the denormal case, we do this instead:
uint64_t major = val < (1ULL << precision)
? 0ULL
: 64ULL - __builtin_clzl(val) - precision;

Then to get the minor component, we right-shift val by major bits, unless it is a denormal, in which case the minor component is the value itself:
uint64_t minor = val < (1 << precision)
? val
: (val >> (major - 1ULL)) & ((1ULL << precision) - 1ULL);

Then the histogram bucket for a given value can be computed directly:
uint64_t idx = (major << precision) | minor;

Of course, we would prefer to bound our storage, hence the consideration about 37 total bits in 100 seconds of nanoseconds. So let’s do that, and record any out-of-bounds value in the special last bucket, indicating that we need to expand our histogram next time:
if (idx >= (max_value_bits << precision))
idx = max_value_bits << precision;

The histogram itself can then be defined simply as having enough buckets for all major and minor components in range, plus one for overflow:
struct histogram {
uint32_t buckets[(max_value_bits << precision) + 1];
};

Getting back the lower bound for a bucket is similarly simple, again with a case for denormals:
uint64_t major = idx >> precision;
uint64_t minor = idx & ((1ULL << precision) - 1ULL);
uint64_t min_val = major
? ((1ULL << precision) | minor) << (major - 1ULL)
: minor;

y u no library

How many lines of code does something need to be before you will include it as a library instead of re-implementing? If I am honest with myself, there is no such limit, as far as code goes at least: only a limit of time. I am happy to re-implement anything; time is my only enemy. But strategically speaking, time too is the fulcrum: if I can save time by re-implementing over integrating a library, I will certainly hack.

The canonical library in this domain isHdrHistogram. But even the C port is thousands of lines of code! A histogram should not take that much code! Hence this blog post today. I think what we have above is sufficient. HdrHistogram’s documentation speaks in terms of base-10 digits of precision, but that is easily translated to base-2 digits: if you want 0.1% precision, then in base-2 you’ll need 10 bits; no problem.

I should of course mention that HdrHistogram includes an API that compensates for coordinated omission, but I think such an API is straigtforward to build on top of the basics.

My code, for what it is worth, and which may indeed be buggy, is over here. But don’t re-use it: write your own. It could be much nicer in C++ or Rust, or any other language.

Finally, I would note that somehow this feels very basic; surely there is prior art? I feel like in 2003, Google would have had a better answer than today; alack. Pointers appreciated to other references, and if you find them, do tell me more about your search strategy, because mine is inadequate. Until then, gram you later!

https://wingolog.org/archives/2023/12/10/a-simple-hdr-histogram

Today, a followup to yesterday’s note with some more details on V8’s new young-generation implementation, minor mark-sweep or MinorMS.

A caveat again: these observations are just from reading the code; I haven’t run these past the MinorMS authors yet, so any of these details might be misunderstandings.

The MinorMS nursery consists of pages, each of which is 256 kB, unless huge-page mode is on, in which case they are 2 MB. The total default size of the nursery is 72 MB by default, or 144 MB if pointer compression is off.

There can be multiple threads allocating into the nursery, but let’s focus on the main allocator, which is used on the main thread. Nursery allocation is bump-pointer, whether in a MinorMS page or scavenger semi-space. Bump-pointer regions are called linear allocation buffers, and often abbreviated as Labin the source, though the class isLinearAllocationArea.

If the current bump-pointer region is too small for the current allocation, the nursery implementation finds another one, or triggers a collection. For the MinorMS nursery, each page collects the set of allocatable spans in a free list; if the free-list is non-empty, it pops off one entry as the current and tries again.

Otherwise, MinorMS needs another page, and specifically a swept page: a page which has been visited since the last GC, and whose spans of unused memory have been collected into a free-list. There is a concurrent sweeping task which should usually run ahead of the mutator, but if there is no swept page available, the allocator might need to sweep some. This logic is inMainAllocator::RefillLabMain.

Finally, if all pages are swept and there’s no Lab big enough for the current allocation, we trigger collection from the roots. The initial roots are the remembered set: pointers from old objects to new objects. Most of the trace happens concurrently with the mutator; when the nursery utilisation rises over 90%, V8 will kick off concurrent marking tasks.

Then once the mutator actually runs out of space, it pauses, drains any pending marking work, marks conservative roots, then drains again. I am not sure whether MinorMS with conservative stack scanning visits the whole C/C++ stacks or whether it manages to install some barriers (i.e. “don’t scan deeper than 5 frames because we collected then, and so all older frames are older”); dunno. All of this logic is inMinorMarkSweepCollector::MarkLiveObjects.

Marking traces the object graph, setting object mark bits. It does not trace pages. However, the MinorMS space promotes in units of pages. So how to decide what pages to promote? The answer is that sweeping partitions the MinorMS pages into empty, recycled, aging, and promoted pages.

Empty pages have no surviving objects, and are very useful because they can be given back to the operating system if needed or shuffled around elsewhere in the system. If they are re-used for allocation, they do not need to be swept.

Recycled pages have some survivors, but not many; MinorMS keeps the page around for allocation in the next cycle, because it has enough empty space. By default, a page is recyclable if it has 50% or more free space after a minor collection, or 30% after a major collection. MinorMS also promotes a page eagerly if in the last cycle, we only managed to allocate into 30% or less of its empty space, probably due to fragmentation. These pages need to be swept before re-use.

Finally, MinorMS doesn’t let pages be recycled indefinitely: after 4 minor cycles, a page goes into the aging pool, in which it is kept unavailable for allocation for one cycle, but is not yet promoted. This allows any new allocations on that page in the previous cycle age out and probably die, preventing premature tenuring.

And that’s it. Next time, a note on a way in which generational collectors can run out of memory. Have a nice weekend, hackfolk!

https://wingolog.org/archives/2023/12/08/v8s-mark-sweep-nursery

Captain, status report: I’m down here in a Jeffries tube, poking at V8’s garbage collector. However, despite working on other areas of the project recently, V8 is now so large that it’s necessary to ignore whole subsystems when working on any given task. But now I’m looking at the GC in anger: what is its deal? What does V8’s GC even look like these days?

The last public article on the structure of V8’s garbage collector was in 2019; fine enough, but dated. Now in the evening of 2023 I think it could be useful to revisit it and try to summarize the changes since then. At least, it would have been useful to me had someone else written this article.

To my mind, work on V8’s GC has had three main goals over the last 5 years: improving interactions between the managed heap and C++, improving security, and increasing concurrency. Let’s visit these in turn.

C++ and GC

Building on the 2018 integration of the Oilpan tracing garbage collector into the Blink web engine, there was some refactoring to move the implementation of Oilpan into V8 itself. Oilpan is known internally as cppgc.

I find the cppgc name a bit annoying because I can never remember what it refers to, because of the other thing that has been happpening in C++ integration: a migration away from precise roots and instead towards conservative root-finding.

Some notes here: with conservative stack scanning, we can hope for better mutator throughput and fewer bugs. The throughput comes from not having to put all live pointers in memory; the compiler can keep them in registers, and avoid managing the HandleScope. You may be able to avoid the compile-time and space costs of stack maps (side tables telling the collector where the pointers are). There are also two classes of bug that we can avoid: holding on to a handle past the lifetime of a handlescope, and holding on to a raw pointer (instead of a handle) during a potential GC point.

Somewhat confusingly, it would seem that conservative stack scanning has garnered the acronym “CSS” inside V8. What does CSS have to do with GC?, I ask. I know the answer but my brain keeps asking the question.

In exchange for this goodness, conservative stack scanning means that because you can’t be sure that a word on the stack refers to an object and isn’t just a spicy integer, you can’t move objects that might be the target of a conservative root. And indeed the conservative edge might actually not point to the start of the object; it could be an interior pointer, which places additional constraints on the heap, that it be able to resolve internal pointers.

Security

Which brings us to security and the admirable nihilism of the sandbox effort. The idea is that everything is terrible, so why not just assume that no word is safe and that an attacker can modify any word they can address. The only way to limit the scope of an attacker’s modifications is then to limit the address space. This happens firstly by pointer compression, which happily also has some delightful speed and throughput benefits. Then the pointer cage is placed within a larger cage, and off-heap data such as Wasm memories and array buffers go in that larger cage. Any neededexecutable codeor external objectis accessed indirectly, through dedicated tables.

However, this indirection comes with a cost of a proliferation in the number of spaces. In the beginning, there was just an evacuating newspace, a mark-compact oldspace, and a non-moving large object space. Now there are closer to 20 spaces: a separate code space, a space for read-only objects, a space fortrusted objects, a space for each kind of indirect descriptor used by the sandbox, in addition to spaces for objects that might be shared between threads, newspaces for many of the preceding kinds, and so on. From what I can see, managing this complexity has taken a significant effort. The result is pretty good to work with, but you pay for what you get. (Do you get security guarantees? I don’t know enough to say. Better pay some more to be sure.)

Finally, the C++ integration has also had an impact on the spaces structure, and with a security implication to boot. The thing is, conservative roots can’t be moved, but the original evacuating newspace required moveability. One can get around this restriction by pretenuring new allocations from C++ into the mark-compact space, but this would be a performance killer. The solution that V8 is going for is to use the block-structured mark-compact space that is already used for the old-space, but for new allocations. If an object is ever traced during a young-generation collection, its page will be promoted to the old generation, without copying. Originally called minor mark-compact or MinorMC in the commit logs, it was renamed to minor mark-sweep or MinorMS to indicate that it doesn’t actually compact. (V8’s mark-compact old-space doesn’t have to compact: V8 usually chooses to just mark in place. But we call it a mark-compact space because it has that capability.)

This last change is a performance hazard: yes, you keep the desirable bump-pointer allocation scheme for new allocations, but you lose on locality in the old generation, and the rate of promoted bytes will be higher than with the semi-space new-space. The only relief is that for a given new-space size, you can allocate twice as many objects, because you don’t need the copy reserve.

Why do I include this discussion in the security section? Well, becausemost MinorMS commits mention this locked bug. One day we’ll know, but not today. I speculate that evacuating is just too rich a bug farm, especially with concurrency and parallel mutators, and that never-moving collectors will have better security properties. But again, I don’t know for sure, and I prefer to preserve my ability to speculate rather than to ask for too many details.

Concurrency

Speaking of concurrency, ye gods, the last few years have been quite the ride I think. Every phase that can be done in parallel (multiple threads working together to perform GC work) is now fully parallel: semi-space evacuation, mark-space marking and compaction, and sweeping. Every phase that can be done concurrently (where the GC runs threads while the mutator is running) is concurrent: marking and sweeping. A major sweep task can run concurrently with an evacuating minor GC. And, V8 is preparing for multiple mutators running in parallel. It’s all a bit terrifying but again, with engineering investment and a huge farm of fuzzers, it seems to be a doable transition.

Concurrency and threads means that V8 has sprouted new schedulers: should a background task have incremental or concurrent marking? How many sweepers should a given isolate have? How should you pause concurrency when the engine needs to do something gnarly?

The latest in-progress work would appear to be concurrent marking of the new-space. I think we should expect this work to result in a lower overall pause-time, though I am curious also to learn more about the model: how precise is it? Does it allow a lot of slop to get promoted? It seems to have a black allocator, so there will be some slop, but perhaps it can avoid promotion for those pages. I don’t know yet.

Summary

Yeah, GCs, man. I find the move to a non-moving young generation is quite interesting and I wish the team luck as they whittle down the last sharp edges from the conservative-stack-scanning performance profile. The sandbox is pretty fun too. All good stuff and I look forward to spending a bit more time with it; engineering out.

https://wingolog.org/archives/2023/12/07/the-last-5-years-of-v8s-garbage-collector

A brief meta-note this morning: for the first time in 20 years, I finally got around to updating the web design ofwingolog.org recently and wanted to share a bit about that.

Back when I made the initial wingolog design, I was using the then-brand-new Wordpress, Internet Explorer 6 was the most common web browser, CSS wasn’t very good, the Safari browser had just made its first release, smartphones were yet to be invented, and everyone used low-resolution CRT screens. The original design did use CSS instead of tables, thankfully, but it was very narrow and left a lot up to the user agent (notably font choice and size).

These days you can do much better. Even HTML has moved on, with<article>and<aside>and<section>elements. CSS is powerful and interoperable, with grid layout and media queries and :has() and :is() and all kinds of fun selectors. And, we have web fonts.

I probably would have stuck with the old design if it were readable, but with pixel counts growing, the saturated red bands on the sides flooded the screen, leaving the reader feeling like they were driving into headlights in the rain.

Anyway, the new design is a bit more peaceful, I hope. Feedback welcome.

I’m using grid layout, but not in the way that I thought I would. From reading the documentation, I had the impression that the element withdisplay: grid would be a kind of flexible corkboard which could be filled up by any child element. However, that’s not quite true: it only works for direct children, which means your HTML does have to match the needs of the grid. Grandchildren can take their rows and columns from grandparents via subgrid, but only really display inside themselves: you can’t pop a grandkid out to a grandparent grid area. (Or maybe you can! It’s a powerful facility and I don’t claim to fully understand it.)

Also, as far as I can tell there is no provision to fill up one grid area with multiple children. Whereas I thought that on the root page, each blog entry would end up in its own grid area, that’s just not the case: you put the <main> (another new element!) in a grid area and let it lay out itself. Fine enough.

I would love to have proper side-notes, and I thought the grid would do something for me there, but it seems that I have to wait for CSS anchor positioning. Until then you can use position: absolute tricks, but side-notes may overlap unless the source article is careful.

For fonts, I dearly wanted proper fonts, but I was always scared of theflash of invisible text. It turns out that with font-display: swap you can guarantee that the user can read text if for some reason your fonts fail to load, at the cost of a later layout shift when the fonts come in. At first I tried Bitstream Charter for the body typeface, but I was unable to nicely mix it with Fira Mono without line-heights getting all wonky: a <code> tag on a line would make that line too high. I tried all kinds of adjustments in the @font-face but finally decided to follow my heart and buy a font. Or two. And then sheepishly admit it to my spouse the next morning. You are reading this in Valkyrie, and the headings areHermes Maia. I’m pretty happy with the result and I hope you are too. They are loaded from my server, to which the browser already has a TCP and TLS connection, so it would seem that the performance impact is minimal.

Part of getting performance was to inline my CSS file into the web pages produced by the blog software, allowing the browser to go ahead and lay things out as they should be without waiting on a chained secondary request to get the layout.

Finally, I did finally break down and teach my blog software’s marxdown parserabout “smart quotes” and em dashes and en dashes. I couldn’t make this post in good faith without it; “the guy yammers on about web design and not only is he not a designer, he uses ugly quotes”, &c, &c...

Finally finally, some recommendations: I really enjoyed reading Erik Spiekermann’s Stop Stealing Sheep, 4th ed.on typography and type, which led to a raft of book purchases. Eric Meyers and Estelle Weyl’s CSS: The Definitive Guide was very useful for figuring out what is possible with CSS and how to make it happen. It’s a guide, though, and is not very opinionated; you might find Matthew Butterick’s Practical Typography to be useful if you are looking for pretty-good opinions about what to make.

Onwards and upwards!

https://wingolog.org/archives/2023/12/05/colophonwards

We are excited to announce the creation of an EU-funded consortium with the central objective to launch GNU Taler as a privacy-preserving payment system across Europe.

https://taler.net/en/news/2023-12.html

Have you written a Docker Registry API client in GitLab CI/CD YAML? I have.
# Delete candidate image from CI repository.
clean-image:
stage: .post
except:
- main

variables:
AUTH_API: "$CI_SERVER_URL/jwt/auth"
SCOPE: "repository:$CI_PROJECT_PATH"
REGISTRY_API: "https://$CI_REGISTRY/v2/$CI_PROJECT_PATH"

before_script:
- >
which jq >/dev/null
|| (sudo apt-get update
&& sudo apt-get -y install jq)

script:
- echo "Deleting $CANDIDATE_IMAGE"
- >
TOKEN=$(curl -s
-u "$CI_REGISTRY_USER:$CI_REGISTRY_PASSWORD"
"$AUTH_API?service=container_registry&scope=$SCOPE:delete,pull"
| jq -r .token)
- >
DIGEST=$(curl -s -I
-H "Authorization: Bearer $TOKEN"
-H "Accept: application/vnd.docker.distribution.manifest.v2+json"
"$REGISTRY_API/manifests/$CI_COMMIT_SHORT_SHA"
| tr -d "\r"
| grep -i "^docker-content-digest: "
| sed "s/^[^:]*: *//")
- >
curl -s
-X DELETE
-H "Authorization: Bearer $TOKEN"
"$REGISTRY_API/manifests/"$(echo $DIGEST | sed "s/:/%3A/g")

https://gbenson.net/gitlab-yaml-docker-registry-client/